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Abstract 

This paper gives two new categorical characterisations of lenses: one as a coalgebra of the 
store comonad, and the other as a monoidal natural transformation on a category of a cer¬ 
tain class of coalgebras. The store comonad of the first characterisation can be generalized 
to a Cartesian store comonad, and the coalgebras of this Cartesian store comonad turn out 
to be exactly the Biplates of the Uniplate generic programming library. On the other 
hand, the monoidal natural transformations on functors can be generalized to work on a 
category of more specific coalgebras. This generalization turns out to be the type of 
compos from the Compos generic programming library. A theorem, originally conjectured 
by van Laarhoven, proves that these two generalizations are isomorphic, thus the core data 
types of the Uniplate and Compos libraries supporting generic program on single recursive 
types are the same. Both the Uniplate and Compos libraries generalize this core function¬ 
ality to support mutually recursive types in different ways. This paper proposes a third 
extension to support mutually recursive data types that is as powerful as Compos and as 
easy to use as Uniplate. This proposal, called Multiplate, only requires rank 3 polymor¬ 
phism in addition to the normal type class mechanism of Haskell. 

Keywords: lens, functional reference, applicative, comonad, coalgebra, monoidal functor, 
monoidal natural transformation, generic programming 
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1 Introduction 

When programming, we often have tree-like data structures that we want to manipulate by 
pulling out some subtree and replacing it with a new subtree of the same type. This is especially 
true when manipulating abstract syntax trees where we often want to apply a transformation to 
all subtrees of a certain type and often these abstract syntax trees are built from mutually 
recursive data types. 

Consider the following small example language [1]. 

data Stm := SDecI TypVar 
SAss Var Expr 
SBIock [Stm] 

SReturn Expr 

data Expr:= EStm Stm 

EAdd ExprExpr 
EVar Var 
Elnt Int 









2 Section 1 


data Var:= V String 
data Typ := Tint 
TFIoat 

If you want to write a function that given a Stm or an Expr renames all variable names by 
prepending an underscore then, naively, you would write two mutually recursive functions to 
traverse the statements and expressions down to the variable names (see Figure 1). These mutu¬ 
ally recursive functions must have a case for each constructor, and for every function like this 
you would have to write another pair of mutually recursive functions. 

As the abstract data type grows in complexity, and as the number of such functions grows, 
the amount of boilerplate code needed also grows; however, all this boilerplate code is essentially 
the same. Therefore, we would like to find a way to abstract away this common functionality. 

renameStm (SDecliv) := SDecI t (renameVarv) 

renameStm (SAssue) := SAss (renameVaru) (renameExpre) 

renameStm (SBIockss) := SBIock (map renameStm ss) 

renameStm (SReturne) := SReturn (renameExpre) 

renameExpr (EStm s) := EStm (renameStm s) 

renameExpr (EAdde^) := EAdd (renameExpr ei) (renameExpr e^) 

renameExpr (EVaru) := EVar (renameVaru) 

renameExpr (Elnt*) := Elnti 

renameVar (Vs) := V(’_’:s) 

Figure 1. Naive method of prepending an underscore to all variable names in an abstract syntax tree 

Over the last several years many libraries supporting such generic functional programming 
have appeared. See Rodriguez et al. [9] for a comparison of nine such libraries. Most of these 
libraries make heavy use of either compile-time or run-time syntax reflection and require com¬ 
piler support. In this paper, we will only be concerned with the light-weight generic program¬ 
ming libraries such as Uniplate [7] and Compos [1] which are semantics based as opposed to 
syntax based. With semantics based generic programming one can explicitly define what the 
substructures of a data type are as opposed to having to deriving this from the syntax of the 
type declaration. With a semantics based generic programing one can define abstract substruc¬ 
tures that are not necessarily syntactical substructures (for example, you can manipulate the 
coefficients of a sparse matrix as if it were a dense matrix). 

In this paper, we will show that two of these competing light-weight libraries, Uniplate and 
Compos, are using (morally speaking) isomorphic data types for their core functionality on 
single recursive data types. Each library extends this common core functionality to support 
mutually recursive data types in different ways. In this paper, we will develop a third library for 
generic programming on mutually recursive data types called Multiplate that only uses rank 3 
polymorphism in addition to the normal type class mechanism of Haskell. With Multiplate, and 
small amount of initial boilerplate code, we can then write the above rename function as simply: 

rename := mapFamily (purePlate {var := A(V s) -* pure s))}) 

renameStm := stm rename 1 
renameExpr := expr rename 

However, before building this library we will first review the most basic structure used for 
manipulating subexpressions: lenses. The lens structure, also known as a functional reference or 
an accessor, is defined as a pair of a getter and a setter functions for a structure of type a and a 
substructure of type /3. 


1. Actually, in Haskell one would need to write renameStm := runldentity o stm rename. I am omitting the new- 
type wrappers and unwrappers in order to clarify the real content of the functions. 
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data Lens a/3 := Address < ® et " a 
( set :: a 

Lenses are particularly nice to work with because they can be composed and because they 
are first class values, they can also be passed around as parameters. One can use lenses to get, 
set, and modify a particular substructure of a given structure. 

In sections 2.2 and 4.1, we will see two different representations of this lens data structure. 
This paper gives two novel characterisations of lenses, the first as a coalgebra of the store 
comonad, and the second as a monoidal natural transformation. 

Building upon this foundation, we show in Section 3.2 that the core data type from Uniplate, 
called Biplate, is morally speaking, a generalization of the first lens representation. We give a 
novel characterisation of Biplates by showing that they are the coalgebras of the Cartesian store 
comonad. 

On the other hand, we will show in Section 4.2 that the core data type used in Compos is a 
generalisation of the second representation of a lens. We note that the laws for Compos are also 
the laws of a monoidal natural transformation. We show that the two core data types of 
Compos and Uniplate are isomorphic using a theorem originally conjectured by van 
Laarhoven [13]. 

Using this new theoretical foundation, we build the Multiplate library. Multiplate uses 
monoidal natural transformations of a vector of coalgebras as its core data type. By using this 
new vector approach, Multiplate can support mutually recursive data types as easily as Compos 
and Uniplate support single recursive data types. 

1.1 Notation 

In this paper I will be using a informal language that is somewhere between Haskell and system 
F w . As in system F w , I will explicitly pass type parameters to functions. However, to lower the 
noise of notation, these parameters will be passed as subscripts and omitted all together when it 
is clear from context what they should be. In practice, this makes the expressions look like 
Haskell expressions most of the time. 

Another difference between Haskell and my notation is that I will allow class instances to be 
defined on type synonyms. For example, I define the instances for the identity applicative 
functor [6] and the composition of applicative functors as follows. 2 

type Id a := a 

instance Functor Id where 

fmap fx:=fx 

instance Applicative Id where 
pure® := x 

f{*)x:=fx 

type (FoG)a := F(Ga) 

instance (Functor F, Functor G) => Functor (FoG) where 
fmapiroG fx := fmap^ (fmapc/) x 

instance (Applicative F, Applicative G) ^Applicative (FoG) where 
pureFoGZ := purej? (puree x) 

f (*)foG x:= ((*)g) ($) f / ( *)f x 


2. The ($) operator is infix notation for the fmap function and the (*) operator is infix notation for the ap 
function. These two operators associate the same way function application does, so f ($)x(*)y(*)z stands for 
((f ($)x){*)y)(*)z. This example is a common idiom for lifting a pure 3-ary function / and applying it to three 
applicative arguments. 


-+/3 1 
->• / 
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This use of type synonyms instances is for presentation purposes only and it is not required. 
In a Haskell implementation, one would make instances on newtype wrappers. Avoiding wrap¬ 
ping and unwrapping newtypes makes the presentation here clearer. 


2 The Store Comonad and Lenses 

A comonad is a type constructor class that is dual to the well-known monad class. 

class Functor w =>• Comonad w where 

extract ::wa—>a 


duplicate :: wa—tw(wa) 

duplicate := extend id 

extend :: (wa —t 7) —> wa —> W'y 

extend fx := fmap / (duplicates) 

Here extract is dual to return, duplicate is dual to join, and extend is dual to (=C). In analogy 
with monads, extract and duplicate form a minimal definition of the comonad class, and extract 
and extend also form a minimal definition of the comonad class. Again, in analogy with monad, 
if one defines extract and extend first, one can obtain fmap for free by defining it to be liftW. 

liftW:: Comonad te=> (a—t /3) -twa-twfi 
liftW/:= extend (/o extract) 


Comonads are subject to the comonad laws. In addition to the two functor laws, there are 
five laws that need to be satisfied. 


extract o fmap / 
duplicate o fmap / 
extract o duplicate 
fmap extract o duplicate 
fmap duplicateo duplicate 


/ o extract 

fmap (fmap /) o duplicate 

id 

id 

duplicate o duplicate 


The first two of these laws are the naturality conditions and they come for free [16] (assuming 
that fmap already satisfies the functor laws). The last three laws of the coherence conditions and 
they need to be verified for each potential comonad. 


2.1 The Store Comonad 

One of the primary comonads of interest in this paper is the Store comonad, which is dual to the 
State monad. 3 It is defined as 

data Store /3a := Store | pee k " @ 

\pos I ffi 

A value of type Store (3a represents a collection of values of type a, where each element of 
the collection is indexed by a value of /3. There is one element for every (3. The collection is rep¬ 
resented by the peek component of type /3 —> a. Within the collection there is one spe¬ 
cial “selected” location. The index for this special location is represented by the pos component 
of type /3. Figure 2 illustrates what values of this data type look like. 


3. This dual of the state monad has been given many different names: costate, state-in-context, context, 
FunArg [10], array. I am proposing yet another name. 


} 
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Figure 2. Illustration of a value of type Store /3 a. A collection of various values of type a is denoted by a circle 
with A’s inside. Even though the values can vary, for this illustration I just use A everywhere. Each value A 
belongs to a location labeled with bj. There is one location for each value of /3 and all locations are occupied. 
This illustration shows only five locations. Among all the locations, there is one location that is selected, which is 
indicated by the heavy outlined location. One can think of this location as where a reading head on a disk platter 
is parked or where a forklift in a warehouse is parked. In this example, the location b 3 is selected. The value held 
in this location is the value returned by extract. 

The data type Store /3 forms a comonad for every fJ with the following comonadic operations. 

instance Functor (Store j3) where 
fmap / (Store vb) := Store {fov)b 


instance Comonad (Store (3) where 
extract (Store vb) := vb 
duplicate (Store vb) := Store (Store v) b 

The fmap function applies a function to each value at each location. The extract function 
returns the value held in the selected location. The duplicate function is more interesting. It pro¬ 
duces a collection of all the possible selections for the input. This collection is arranged so that 
a copy of the original collection but with cell b i selected is put into cell b ( . See Figure 3 for an 
illustration of a result of duplicate. Notice that the original collection ends up placed in the orig¬ 
inally selected cell. This property is one of the comonad laws: 

extract o duplicate = id 



Figure 3. An illustration of the result of duplicate applied to the input illustrated in Figure 2. 
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The function extend takes a given function operating on stores and applies it to all possible 
selections of the given store. 


2.2 Lenses 

A lens can be represented by the following data type, 
type Lens aj3:=a -»Store /3 a 

The most typical use case for a lens is as a function reference to access a field of a record. 
For example, suppose we have the following record structure for data for an address book [2]: 

... f phone :: PhoneNumber 
data Address := Address < , 

[ website_ :: URI 

We might define address data for Pat as follows: 

... [phone := 333-4444 1 

pa . ress [website_ := http://pat.com/ J 

We can make a lens that is a reference to the phone number field of the record, 
phone :: Lens Address PhoneNumber 

phone := Aaddress—t Store (AnewPhone—t address{ phone_ := newPhone}) (phone_ address ) 

A similar lens for the website field can also be defined. 

The phone lens pairs up the getter and setter functions to access to a single Address into one 
Store PhoneNumber Address comonadic value. The pos component of the store value is the phone 
number of the given address. The peek component of the store value is an update function that, 
given a new phone number, returns a new address with an updated phone number. 

A more denotative perspective views this lens as a function that given an address returns a 
store consisting of all the possible addresses formed by updating the input address with all pos¬ 
sible different phone numbers where each possible address is located in the box labeled by the 
updated phone number. The selected value is the one box labeled with the current phone 
number and it contains the original address. 

A lens is isomorphic to a pair of getter and setter functions 

Lens a/3« (a-)-/3) x (a —> j3 —>a) 

The functions that implement this isomorphism are as follows. Given a lens we can retrieve the 
getter and setter functions. 

get :: Lens a /3 —>■«—>■ /3 
get la := pos (la) 

set :: Lensa/3—>■ /3—»• a 
set la:= peek (l a) 

Conversely, given getter and setter functions we can build a lens. 

lens :: (a -4 /3) -> (a ->• (3 ->• a) -* Lens a /3 
lens gtst:= Aa—Store ( sta ) ( gta ) 
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Using the get and set functions we can retrieve and update the fields of our record. The fol¬ 
lowing are examples of accesses the phone field of the pat record: 

get phone pat = 333-4444 

. , 4.rrr CCCC A .i /phone := 555-6666 1 

set phone pat 555-6666 = Address , > 

/website_ := http://pat.com/ J 

We expect the get and set functions to satisfy certain laws. Kagawa [4] lists three laws which 
agree with the laws of a “very well behaved lens” [2], 

getZ (setZsfr) = b (1) 

set Is (get Is) = s 
setZ (setZs^i) 62 = set Z 562 

It is possible to reexpress these laws using the comonadic operations for the store comonad. 

extract oZ = id (2) 

fmapZoZ = duplicate oZ 

A proof that for all Z of type Lens a 8 (1) holds if and only if (2) holds can be found in the sup¬ 
plementary material [8]. 

In general, a coalgebra for a functor F is simply a function /:: A —> FA for some type A. 
However, when W is a comonad, we say that f:: A —> WA is a coalgebra for the comonad W 
when the above two laws are satisfied. This means that lenses are exactly the coalgebras for the 
store comonad! 4 

Lenses can refer to more than just fields of records. They can be used to reference to an ele¬ 
ment in an array or any substructure of a larger structure, or anything else that satisfies the lens 
laws above. 

Lenses are also composable in the sense that they form a category. For any data structure 
there is a trivial identity reference from itself to itself. If you have a lens referring to a field of a 
record and another lens that refers to a field of that field, then those two lenses can be combined 
into a lens that refers directly to the inner field from the outermost record. 


idLens :: Lens a a 
idLens:= Store id 


composeLens:: Lens 8l^ Lens a/3 -»Lensa7 
Zi ‘composeLens 1 12 := Aa—» let Store vb := Z2ainfmap v (Zi 6) 

In Section 4, we will see a different representation of lenses where lens composition is repre¬ 
sented directly by function composition. 

2.2.1 The Duplicate Lens 

For any comonad W and for any type a, the duplicate function is a coalgebra for W. This 
means that duplicate is some sort of lens for the store comonad. 

duplicate:: Lens (Store /3 a) /3 


4. Johnson et. al. shows that 


also the algebras of a certain monad 


slice category [3]. 
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We see by this signature that duplicate is a reference to a /3 field of the Store f3a record. It is 
not hard to see that this lens is a reference to the pos component of the Store /3a. This lens can 
be used to get and set the selected location in a store. 


3 The Cartesian Store Comonad and Biplates 

Mitchell and Runciman [7] define their BiplateType, which we will call Biplate, as follows. 

type Biplate a (3 := a-s> ([£] x ([/3] -> a)) 

We can see that this data type as it stands is isomorphic to Lens a [/?]; however, Biplates 
have the constraint that only lists of the same length as the first [/?] component are accepted by 
the second |jfl —> a component. In this sense, Biplates are functional references to multiple sub¬ 
structures at the same time. These substructures can be retrieved and simultaneously updated 
similar to lenses. 

Mitchell and Runciman would really prefer to write the following data type. 

type Biplate a/3 := a -»• 3n:: N. /?" x (/?" a) 

However, this data type cannot be expressed as such in Haskell, so they are forced to use a 
data type coarser than they really want. It is too bad that we cannot express such a type in 
Haskell because 3n::N. f3 n x ( (3 n —> a) forms a comonad similar to the store comonad. Or is 
there a way to express this type in Haskell? 


3.1 The Cartesian Store Comonad 

One natural way of expressing the type 3n::N. /3 n x {J3 n —> a) in Haskell is using GADTs with 
type level natural numbers to create a type of vectors. However, van Laarhoven has defined a 
type isomorphic to our desired comonad directly using nested data types [13] which works in 
plain Haskell ’98. van Laarhoven called his data type FunList, 5 but I will call it the Cartesian 
store comonad. 

data CartesianStore (3a := Unit a 

| Battery (CartesianStore /J ((3a)) (3 


A proof that this CartesianStore (3a data type is isomorphic to 3n::N. (3 n x (J3 n —s> a) can be 
found in the supplementary material [8]. When thinking about the semantics of the Cartesian 
store, it is helpful to keep the 3n::N. /3" x (0 n —> a) representation in mind. The dimension of a 
Cartesian store can be computed by counting the number of Battery constructors. 

dimension :: CartesianStore (3a— 

dimension (Unit _) := 0 

dimension (Battery v _) := succ (dimension v) 

The Cartesian store data type is similar to the store data type. The difference is that in the 
Cartesian store data type labels have some extra structure. The items are indexed by a coordi¬ 
nate system of some dimension. Figure 4 illustrates what a value of a Cartesian store of dimen¬ 
sion two looks like. 


5. This is presumably in reference to FunArg which is Uustalu and Vene’s [10] 


for the 


comonad. 
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Figure 4. An illustration of a value of a Cartesian store comonad. This particular value is two dimensional. The 
selected location is at ( 62 , 63 )- Although this figure shows each row and column having a particular order, in a 
Cartesian store comonad the columns do not necessarily have any particular order within them. On the other 
hand, the dimensions within the Cartesian store comonad are ordered. The vector used to index has particular 
first, second, ..., n th components. 

van Laarhoven defines comonadic operations for the Cartesian store as follows: 

instance Functor (CartesianStore /3) where 
fmap/(Unita) :=Unit(/a) 
fmap / (Battery vb) := Battery (fmap (/o) v) b 

instance Comonad (CartesianStore f3) where 
extract (Unit a) := a 
extract (Battery vb) := extract vb 
duplicate (Unita) := Unit (Unita) 
duplicate (Battery vb) := Battery (extend Batteryn)6 

The extra structure in the Cartesian store allows us to make an instance of another familiar 
structure: an applicative functor. Recall that the Applicative class requires two functions, pure 
and (*), in addition to a Functor prerequisite. 

class Functor Applicative k where 
pure :: a—>na 

((*)):: k (a —> 7) —>■ na —> K'y 


McBride and Paterson 
that the Cartesian store i 
tions [12]: 


; laws for an applicative functor [6]. van Laarhoven shows 
istance of an applicative functor with the following func- 


instance Applicative (CartesianStore /?) where 
pure := Unit 

/(*) (Unita) :=fmap($a)/ 

/ <*} (Battery vb) := Battery ((o) ($) / <*) v) b 

This applicative functor instance will play an important role later in Section 4.2. A proof that 
this is an applicative functor can be found in the supplementary material [8]. 

A Cartesian store is a generalization of a store. Every store can be transformed into a one 
dimensional Cartesian store using the singleStore injection below. 
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singleStore :: Store (3a —> CartesianStore /3a 
singleStore (Stored) := Battery (Unitu) b 

We can also strip off the leading dimension of a Cartesian store (if the dimension is non-zero) 
as a store, leaving another Cartesian store with dimension one less. 

stripDimension:: CartesianStore /3a-t Maybe (Store (3a x CartesianStore /3a) 
stripDimension (Unita) := Nothing 

stripDimension (Battery vb) := Just (Store (extracts) b, fmap ($6) v) 

By iterating stripDimension, we can produce a list of stores that include the results of varying 
a single dimension of the original Cartesian store while keeping the coordinate of all the other 
dimensions fixed. 

stores:: CartesianStore /3a-> [Store /3a] 
stores := unfoldr stripDimension 

Note that only the data along the “axes” around the selected position in the Cartesian store 
is preserved by stores. The rest of the information in the structure is lost. 

3.2 Biplates 

From the previous section we saw that we can define a comonad in Haskell that captures the 
invariant that the function component of the result only accepts inputs that are the same length 
as the data component of the value. A Biplate is thus defined: 

type Biplate a (3:=a-> CartesianStore (3a 

Once we define Biplates this way, it is natural to require that they be coalgebras of the 
Cartesian store comonad. As such, they need to satisfy the two laws for coalgebras: 

extract ol = id 
fmapio/ = duplicate ol 

This will imply laws about getting and setting values with a Biplate. Neither the above laws nor 
anything equivalent appear in Mitchell and Runciman’s paper [7] but they are implicit in one’s 
understanding of their work. 

A Biplate is a generalization of lens because composing with singleStore is an injection from 
lenses to Biplates. To understand what this injection is doing, recall that a lens denotes a refer¬ 
ence to a substructure inside some larger structure while a Biplate allows one to reference an 
ordered list of zero or more substructures of the same type inside a some larger structure. In 
this sense we see that a lens is a specialization of Biplates where the number of substructures 
referenced is exactly one. Thus we can consider Biplates to be a functional multireferences. This 
generalization of lenses is what van Laarhoven was after in his work. 

In Mitchell and Runciman’s work [7], canonical Biplates for structures are defined using 
Haskell’s class mechanism. These canonical Biplates reference the maximal subexpressions, or 
children, of the larger structure. With these canonical Biplates, Mitchell and Runciman build a 
library of fast, lightweight, generic traversal functions for structures. 

Biplates also form a category in a similar way to lenses. There is an identity Biplate and a 
way of composing Biplates. 


idBiplate:: Biplateaa 
idBiplate := Battery (Unit id) 
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composeBiplate:: Biplate /3-y—Biplate a(3 -> Biplate 07 
composeBiplate 0102 := f 002 

where 

f:: CartesianStore (36 -»• CartesianStore 7(5 
f(Unita) := Unita 
f (Battery vb) := f v (*) o\ b 


4 Polymorphic Representations 

Given types A and H, another representation of the Store AH, derived from van Laarhoven’s 
work [11], is 

Vk :: Functor. ( B -4 kH) — t k A 

The idea is that the parametricity of values of this type will greatly restrict what values of this 
data type can be. Since a value of this type has to work for any functor k, the only tool avail¬ 
able is fmap K . There is no way for this function to produce a value of kt for any type r except 
by utilizing its parameter / :: B —>• kH. So a value of this type must internally hold on to a value 
b ::B and then apply / to it yielding fb :: kB. However, it still needs to produce a value of K A. 
If this value also internally holds a value v :: H—>A, then it could use fmap K v to transform kB 
into a kA. Notice that our value cannot hold internally a value of type kB —> k A, because k is a 
parameter of the polymorphic function which is not available at definition time. 

We see that if we have a B and a B—tA, then we can produce such a polymorphic function. 
These two values are exactly the two components of Store HA. 

isoStorei:: Store HA-A/k :: Functor. (B —> kB ) —> kA 
isoStorei (Store v b) : = Ak —»■ Xf —■» fma p K v ( fb) 

It turns out that, using the free theorem [16] for this polymorphic type [15], we can prove 
that these are effectively the only values that this polymorphic type has. A proof that the types 
Store HA and the polymorphic type Vk :: Functor. (H—>kH) —> kA are isomorphic can be found in 
the supplementary material [8]. The inverse of isoStorei is defined below. 

isoStore 2 :: (Vk:: Functor. (B-*kB) -t kA) -t Store HA 
isoStore 2 y :=2/(storeB) idLens B 

This isomorphism implies following set of isomorphisms. 

Store HA ?« Vk:: Functor. (H— kB) k A 
Lens AH iss A—Functor. (H-wjH)->kA 
Lens AH ps Vk:: Functor. (H-^kH) ->A->kA 

This last representation of a lens is the van Laarhoven representation of a lens [11], or simply a 
van Laarhoven lens for short. 

The modifier for a van Laarhoven lens is defined by instantiating it at the identity functor, 
Id, yielding a type (H—>H) —> (A—>A); given a function that modifies H, one gets a function that 
modifies A that works by modifying the particular substructure of type H that is referenced by 
the lens. The setter of a van Laarhoven lens can be defined by in terms of the modifier. 

modify:: (Vk:: Functor. (B-> kB) ->A—>kA) (BB)A—> A 
modify y := y u 

set:: (Vk:: Functor. (H—»• kH) —»• A—► kA) -> A— >B—> A 
set yab := modify y (const b) a 
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The getter of a van Laarhoven lens is defined by instantiating it at a constant functor and 
passing in the identity function (compare this with the setter function which is instantiated at 
the identity functor and passed a constant function). 

type Const /3a:= /3 

instance Functor (Const /?) where 
fmap fb:= b 

get :: (Vk :: Functor. ( B HhnB) -tA-t kA) ->A->B 

gety:=y (Co nstB) ids 

Recall that lenses form a category because there is an identity lens and lenses are compos- 
able. van Laarhoven lenses are particularly elegant in this regard, because lens composition is 
implemented as function composition and the identity lens is implemented as the identity func¬ 
tion. A disadvantage of van Laarhoven lenses is it that they require support for rank-2 polymor¬ 
phism to be used effectively. 


4.1 Monoidal Natural Transformations 

Given this isomorphism between the type of lenses and the polymorphic type of van Laarhoven 
lenses, one can transport the lens laws through the isomorphism to get the laws for van 
Laarhoven lenses. However reasoning about van Laarhoven lenses this way is akward. Is there a 
more natural way of expressing the lens laws for van Laarhoven lenses? The answer is: Yes. 
However, to see this we have to first build up a few more definitions. 

type Coalgebra an := a—tna 

The arguments to Coalgebra are flipped from the usual presentation because in this paper we 
want to think of Coalgebra a :: (★ —>• *) —> * as a functor from functors-on-types to types. In par¬ 
ticular, if we have a natural transformation between functors on types (I write => k -2 for the 
type of natural transformations from functor K\ to functor K2), then it can be “mapped” over a 
coalgebra. 

type rci=>K2:=Va.Kia—>K2a 

coalgMap:: («i => K2) -> Coalgeba (3ni ->■ Coalgebra /3k,2 
coalgMap ??c:= 770 c 

We can rewrite the type of a van Laarhoven lens as 
l ::Vk: Functor. Coalgebra Coalgebra Ak 


and we now see that this is the type of a natural transformation from Coalgebra B to Coal¬ 
gebra A. The parametricity of the type of l gives a free theorem that states that l must be a nat¬ 
ural transformation 


or equivalently 


coalgMap 770 / = lo coalgMap 77 


Vc. 77 o (lc) = Z (770 c) 


There is more structure at play here though. Both the category of functors and the category 
of types are monoidal categories. Types form a monoidal category with 1 and x, a.k.a. Carte¬ 
sian products. On the other hand, functors form a monoidal category with Id and o, a.k.a. 
functor composition. Coalgebras preserve this monoidal structure with the following operations . 6 



Polymorphic Representations 


13 


idCoalg :: l-i Coalgebra a Id 

idCoalgQ := id 

composeCoalg:: (Functor ki, Functor k 2 ) => (Coalgebra ccki x Coalgebra a^) —> 

Coalgebra a (Ki o k 2 ) 

composeCoalg (ci, C 2 ) := fmap Kl C 2 °ci 

A proof that these operations satisfy the laws for a monoidal functor can be found in the 
supplementary material [ 8 ]. Given that Coalgebra A and Coalgebra B are both monoidal functors, 
we can now see that l is actually a monoidal natural transformation. 

The laws for a monoidal natural transformation lens are the following. 

I (idCoalg ()) = idCoalg () (3) 

/ (composeCoalg ( 01 , 02 )) = composeCoalg (Zci, IC2) 

In the supplementary material [ 8 ], one can find a proof that these two laws are satisfied exactly 
when the coalgebra laws for the store comonad are satisfied under the isomorphism. Thus our 
three sets of laws, (1), (2) and (3) are all equivalent to each other. This means we have three 
different characterisations of two different representations of a lens structure and its associated 
laws. 


4.2 van Laarhoven Biplates 

A similar polymorphic representation for CartesianStore AB exists: 

Vk :: Applicative. (B-> kB) ->kA 

Just like before, parametricity restricts what these values are able to do. However, since we now 
know that k is an applicative functor, there are more tools available to us. In particular we can 
use pure and (*). 

For example, if our value internally holds a value a:: A, then we can implement this type by 
ignoring the /:: B kB argument and simply return pure K a. Alternatively, if our value is 
holding a value bv.B and a function v:: B— t A, then, we can return pur e K v{*) K fb. Because 

fmap K ux = pure^u (*) K x 

we see that this case is essentially identical to the lens case. We have further possibilities. Our 
value could be holding two values 61 , & 2 :: B and a function v :: B B —> A. In this case we could 
return pure* v (*} K fb\ (*) K /6 2 - We could keep adding more and more Bs and adding more and 
more parameters to v. So essentially, if we have a value of type 

A+{B^A)xB + {B 2 ^A)xB 2 + ... « 3n::N.(B"^A) x B n 
« CartesianStore BA 


we can produce a value of the polymorphic type 

Vk:: Applicative. (B-> kB) ->-kA 

using the following function. 

isoCartesianStorei:: CartesianStore BA —> (Vk :: Applicative. (B —> kB) —> kA) 
isoCartesianStorei (Unito) := Ak-»- A/-* pure K a 

isoCartesianStorei (Battery vb) := Ak-» Xf (isoCartesianStorei v) K f (*) K fb 


6. I have written idCoalg and composeCoalg this way to better show how the monoidal structure is being pre¬ 
served. In real code, one would leave out the useless () input to idCoalg and curry composeCoalg. 
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Section 5 


These are essentially the only possible values of this type, van Laarhoven conjectured that 
the type CartesianStore AB and the polymorphic type Vk:: Applicative. (B— »kB) —>kA are iso¬ 
morphic. I have completed the proof of this isomorphism. The proof can be found in the supple¬ 
mentary material [8]. The inverse to isoCartesianStorei defined as follows: 

isoCartesianStore2:: (Vk :: Applicative. (B —»• kB) —>• kA) —► CartesianStore BA 

isoCartesianStore2 y :=2/(CartesianStoreB) idBiplates 

This isomorphism implies the following set of isomorphisms. 

CartesianStore BA Vk:: Applicative. -Hvi 

BiplateBA « A—>Vk:: Applicative. (B—»kB) —>kA 
Biplate BA « Vk:: Applicative. (B->kB) —»A-»kA 

Just as was the case for lenses, the coalgebra laws for Biplates are equivalent under this isomor¬ 
phism to the laws for a monoidal natural transformation. The proof of this can be found in the 
supplementary material [8]. 

As it turns out, the type Vk:: Applicative. (A— >kA) — >A—>kA is exactly the type of compos 
from the Compos library for generic programming [1], 

Thus we see that, morally, Uniplate and Compos use isomorphic representations. The only 
difference is that Compos’s type more accurately captures the invariants that Uniplate requires 
the user to ensure by hand. In particular, the claim from the Uniplate paper [7] that 

[...] the Compos library is unable to replicate either universe or transform from 
[Uniplate’s] library. 

is false. Because Uniplate and Compos have isomorphic representations, it must be possible to 
implement the functionality of Uniplate using Compos. Once one realizes that it is possible, it is 
not very difficult to implement these functions in Compos. Indeed, in the next section, we will 
be using a Compos-like representation to implement Multiplate, which includes Uniplate’s func¬ 
tionality as a special case. 

A van Laarhoven Biplate can directly been seen as a generalization of a van Laarhoven lens. 
Because every applicative functor is a functor, every van Laarhoven lens is a van Laarhoven 
Biplate. No conversion function is needed. 


5 Multiplate 

Consider again the van Laarhoven representation of a Biplate: 

Vk :: Applicative. (B—>kB) — t (A—>kA) 

Here B is the type of substructures of a larger structure of type A. Suppose we want to extend 
the van Laarhoven Biplate type to support references to multiple different types of substructures 
of A. The natural way to do this is to add more parameters to the type. For example, if we 
want a functional multireference from A to 0 or more substructures of types B and C we would 
use the type 

Vk:: Applicative. (B— »kB) -> (C —>• kC) —>• (A-^kA) 

If A, B, and C are mutually recursive data types, then we want to consider not only the func¬ 
tional multireference from A to its children of types A, B, and C, but also the functional mul¬ 
tireference from B to its children of types A, B, and C and from C to its children of types A, B, 
and C. This means we will want three functional multireferences of types: 

Vk:: Applicative. (A->kA) -A (B->kB) -> (C->kC) -*■ (A->kA) 

Vk:: Applicative. (A-^kA) -> (B->kB) (C^-kC) -t (B^kB) 

Vk:: Applicative. (A-»kA) -a (B-^kB) -> (C^kC) -A {C^kC) 
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The Compos paper [1] claims that 

Even though these implementations would be identical for all type families, it is 
difficult to provide generic implementations of them without resorting to multipa¬ 
rameter type classes and functional dependencies since the type of the function 
tuple will depend on the type family. 

Compos supports mutually recursive data types but at the cost of requiring the user to 
rewrite their data types using GADTs. 

Uniplate, with its isomorphic implementation, resorts to multiparameter type classes to sup¬ 
port generic programming on mutually recursive data types without the need for functional 
dependencies by introducing Biplates. However, Uniplate’s support for mutually recursive data 
types is limited to dealing with one pair of parent-child types at a time. For instance, it is not 
possible to update two types of children in one traversal of a parent type. 

In this section, we propose an alternative method of supporting mutually recursive data 
types that does not require GADTs, nor rewriting one’s data types, nor does it require multipa¬ 
rameter type classes. However, we will make use of rank 3 polymorphism. 

The key observation is that, instead of creating three nearly identical functional multirefer¬ 
ence types, we can combine them into one “matrix transformation” that operates on a “vector” of 
coalgebras. To begin, we define a record type parametrized by applicative functions as follows. 

{ coalgA :: A^-kA \ 
coalgB :: B-> kB > 
coalgC :: C ^ kC ) 

Then we can write one type that incorporates all three of our previous types. 

Vk :: Applicative. P k —> P k . 

Given the record type P, we can provide generic implementations of traversal operations. To see 
how to accomplish this, we will first write non-generic implementation of this for an example 
data type, then we will see how to abstract out the generic components. 


5.1 Mutually Recursive Data Types 

Recall the small language from the Introduction. 

data Stm := SDecI TypVar 
SAss Var Expr 
SBIock [Stm] 

SReturn Expr 

data Expr:= EStm Stm 

EAdd ExprExpr 
EVar Var 
Elnt Int 

data Var := V String 
data Typ := Tint 
TFIoat 

For our implementation, we will need a record type with a field for a coalgebra for each of 
these four types from that small language. This record is parametrized by an applicative 
functor. We will call such a record a plate. 


r stm 

: Stm 

—>«Stm ^ 

J expr 

: Expr 

—>-k Expr [ 

1 var 

: Var 

—Var ( 

[typ 

: Typ 

— >«Typ J 


data Plate k:= Plate 






Section 5 


We first provide the functional multireference that defines the reference to the children of 
each of these data types. We call this functional multireference multiplate and it is defined in 
Figure 5. 


multiplate:: Applicative k=> Plate k-> Plate 
fstm := buildStm 
= buildExpr 
= buildVar 
= buildTyp 


multiplate p:= Plate < expr 
I var 

l typ 


where 

buildStm (SDecIfu) 
buildStm (SAssue) 
buildStm (SBIockss) 
buildStm (SReturne) 
buildExpr (EStm s ) 
buildExpr (EAddeie 2 ) 
buildExpr (EVarv) 
buildExpr x 
buildVar x 
buildTyp x 


= SDecI ($) 
SAss ($} 
= SBIock ($) 
SReturn ($} 
= EStm ($) 
EAdd ($} 
= EVar ($) 
purex 
= purex 
purex 


typ pt 

var pv 

traverse (stm p) 
expr pe 
stmps 
exprpei 
var pv 


(*) var pv 
(*) expr pe 


(*) exprpe 2 


Figure 5. The multiplate function for a little language taken from the Compos paper [1], 

Notice that Elnti has no children (at least no children of type Stm, Expr, Var, or Typ) and in 
this case we simply return the input wrapped in pure and similarly for values of type Var and 
Typ. Also notice that SBIock’s children are held in a list. We use the fact that the list container 
is Traversable in order to collect them. 

Using multiplate, we can recursively define a collection of rename functions, one for each type 
in our mutually recursive collection of types, that prefixes each variable with an underscore. 


rename:: Plate Id 

! stm 
expr 
var 

typ 


stm (multiplate rename) ^ 
expr (multiplate rename) I 
A(V S )^pure, d (V (’_’:*)) f 
typ (multiplate rename) J 


The recursive calls to multiplate rename will cause all of the descendants of statements and 
expressions to be renamed. Each field of this plate will rename variables for a different type. For 
example, stm rename ::Stm —» Stm, can be used to rename variables in statements, and 
expr rename :: Expr—> Expr, can be used to rename variables in expressions. 

Above, we used the method from Compos to create the rename function. Uniplate improves 
upon this by defining generic traversal function that will recursively apply a given transforma¬ 
tion function bottom-up. Since Uniplate is isomorphic to Compos, it must be possible to write 
this generic traversal function in the Compos representation. 

mapFamily 7 :: Plate Id -> Plate Id 

mapFamily p:= p ‘composePlateld' multiplate (mapFamily p) 

where 

composePlateld:: Plate Id —> Plate Id —> Plate Id 


7. These function names are taken from http://www-ps.informatik.uni- 

kiel.de/~sebf/projects/traversal.html. 
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! stm := stm piostm p 2 1 
expr := expr Pl o expr p 2 
var := var piovar p 2 I 
typ := typ piotyp p 2 J 

We can use mapFamily to define rename by applying it to a plate that only renames top-level 
variables. To make such a plate it is easiest to start with a generic pure plate that does nothing. 

purePlate:: Applicative k=> Platen 

! stm := pure 'l 

exPr : = P ure 

var := pure 
typ := pure J 

Now we can override this pure plate and easily obtain a plate that only renames top-level 
variables which we pass to mapFamily to rename all variables. 

rename := mapFamily (purePlate {var := renameVar}) 

where 

renameVar (V s) := pure (V(’_’: s )) 

Notice that now our definition only mentions the types and the cases that we are interested 
in. The rest of the types and cases are handled generically. 

Reviewing our definition of mapFamily, we see that we can generalize composePlateld to work 
over any monad by using the Kleisli composition operator. 


kleisliComposePlate:: Monad m=> Platem—l Platem—i Plate m 
= stm pi«stm p 2 
= expr pi«expr p 2 
= var pi<S<var p 2 
= typ pi<S< typ p2 


Pi ‘kleisliComposePlate 1 p 2 := Plate < 

[typ 


Thus our definition of mapFamily generalizes to arbitrary monads. This yields mapFamilyM. 

mapFamilyM :: Monad m=> Plat enH Plate rn 

mapFamilyM p:=p 'kleisliComposePlate' multiplate (mapFamilyM p) 


5.2 Type-Generic Generic Functions for Mutually Recursive Types 

The functions in the previous section can be used to build generic traversal functions for the 
specific mutually recursive data type we defined in that section. However, we would like to 
define these generic functions generically for all mutually recursive data types. To this end we 
will create a type class for plates. 

For a prospective plate P we will require an instance of the multiplate function having type 

multiplate:: Applicative n => P n —> P k 

We also need a generic way of building plates. Notice that for each of our generic functions 
purePlate, kleisliComposePlate and mapFamilyM, each field of the record is built in a uniform 
way. Therefore, if we are given a polymorphic function of type Vcr.a — > not we can build an arbi¬ 
trary plate Pk for an arbitrary applicative functor k. However, our generic functions also need 
projection function of the field being build. A projection function for a plate P has type Pro¬ 
jector P a defined below. 

type Projector pa := Vk. pn-ta-tna 
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We can pass the projector for the field we are building to a generic builder and have the 
generic builder create each field of our record. To this end we require the user to provide a 
second function for each prospective plate. 

mkPlate:: (Va. Projector pa —> a —>na) —>pK 

Putting these two functions together we form the Multiplate class. 


class Multiplate p where 

multiplate:: Applicative k => pn-¥ pn 
mkPlate :: (Va. Projector pa ->■ a ->■ na) ->• pn 

For our example Plate, the multiplate function is the function defined in the previous section. 
The mkPlate function for Plate is simply 


mkPlate build:= Plate 


! stm := buildstm ) 
expr := buildex pr I 
var := buildv ar ( 
typ := buildtyp ) 


Now we can define purePlate, kleisliComposePlate, and mapFamilyM and more, generically for 
all instances of Multiplate. 


purePlate:: (Multiplatep, Applicative n) => pn 
purePlate := mkPlate (const pure) 


idPlate:: Multiplatep=> p Id 
idPlate := purePlate 


mapPlate:: V/OKi «2- Multiplate p=>- (V7.K17 —> K27) —> pn 1 — » pn2 

mapPlate r\p := mkPlate build 

where 

build:: Projector pa ->• a ->• K2 a 
build 7T := p onp 


composePlate:: Mpn\ K2 -(Multiplate p, Applicative «i, Applicative K2) =» p/ci-t pK2 ~> p(k 2° «i) 
Pi 'composePlate' P2 := mkPlate build 

where 

build:: Projector pa ->■ a -»• K2 («i a) 
build 7T := fmap re2 (7rpi) o np2 

kleisliComposePlate:: (Multiplate p, Monad m) => pm— > pm^r pm 
Pi 'kleisliComposePlate' P2 := mapPlatejoin (pi 'composePlate' P2) 

mapFamilyM :: (Multiplate p, Monad m) =>pm— >• pm 
mapFamilyM p:=p 'kleisliComposePlate' multiplate (mapFamilyM p) 


Here we define kleisliComposePlate in terms of the more general function composePlate. 

We can also write code for generic folding over structures in the same way the Compos does. 
We define appendPlate which combines plates over the applicative constant functor on a monoid. 


instance (Monoid o) ^Applicative (Const 0) where 
pureir := 1 Q 

/ (*) x := f* 0 x 

appendPlate:: Vpo. (Multiplate p, Monoid 0) => p (Const 0) -»■ p (Const o) -»■ p (Const o) 
Pi 'appendPlate' P2 := mkPlate build 
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where 

build:: Projector pa^a^ma 
build ira := npia (* np2 a 

preorderFold :: (Multiplate p, Monoid o) =>■ p (Const o) -s- p (Const o) 
preorderFold p:=p 'appendPlate' multiplate (preorderFold p) 

postorderFold :: (Multiplate p, Monoid o) => p (Const o) ->■ p (Const o) 
postorderFold p := multiplate (postrderFold p) 'appendPlate' p 

Given a plate p that describes how to convert each type of data into a monoid type o, the 
preorderFold and postorderFold functions create a plate of functions that traverses all the descen¬ 
dants of the inputs and combine the results using the monoid operation. 

The function mkPlate is a rank 3 polymorphic function. This is because Projector pa is a 
type polymorphic over all type constructors k, not just the k bound in the type of mkPlate. It is 
important that build’s projection function parameter is polymorphic because it gets instantiated 
to different type constructors for some generic functions. 

5.2.1 Multiplate Laws 

Although this library was built to support plates that define one field for each type in a mutu¬ 
ally recursive set of types, the resulting library is general enough to support any plate structure 
that defines multiplate and mkPlate, so long as it satisfies the multiplate laws: 

multiplate idPlate = idPlate 

multiplate (composePlatepiP2) = composePlate (multiplate p±) (multiplate P2) 

The multiplate laws simply state that multiplate is a monoidal natural transformation and are 
analogous to the laws for van Laarhoven lens that we found in Section 4.1. This means that 
users are free to define multiplate instances however they choose, so long as these two laws are 
satisfied. For example, Visscher shows how to define a plate with one field per constructor of the 
mutually recursive data types [14]. Visscher’s definition of plate turns out to be exactly the type 
MPreserve from “Dealing with Large Bananas” [5]. The types Preserve and Unify can are 
instances of MPreserve at the identity and constant functors respectively. Thus Multiplate cap¬ 
tures much of the functionality of Large Bananas as well as Compos and Uniplate. 


6 Conclusions and Future Work 

In this paper, we defined the store comonad as the dual of the state monad and saw that the 
coalgebras of this comonad exactly characterize lenses. We define the Cartesian store comonad 
as a generalization of the store comonad and noted that it was also an applicative functor. We 
saw that the coalgebras of this comonad exactly characterizes the Biplates from the Uniplate 
library [7]. After this we defined van Laarhoven representations of both lenses and Biplates, van 
Laarhoven lenses are monoidal natural transformations of coalgebras that are polymorphic over 
functors, while van Laarhoven Biplates are monoidal natural transformations of coalgebras that 
are polymorphic over applicative functors. This completes the analogy given in the title of this 
paper: Functors are to Lenses as Applicative is to Biplate. 

Using this theory we derived a new method of doing generic traversals over mutually recur¬ 
sive data types. This requires the user to define a type, called a plate, for a vector of coalgebras 
with one field for each type in the mutually recursive set of types. Then the user creates an 
instance of the Multiplate class for this plate. Once this is defined, all the generic traversal func¬ 
tions of the Multiplate library are available. This paper describes only the most important func¬ 
tions from the Multiplate library. 8 


8. http://hackage.haskell.org/package/multiplate/ 





20 


Section 


The Multiplate library has a number of advantages over other light-weight generic program¬ 
ming libraries. As noted before, Compos requires the user rewrite his data type as a GADT, 
effectively reducing a mutually recursive data type into a single recursive data type. Multiplate 
works with the user’s existing data type. The Biplate mechanism of Uniplate only allows you to 
work with pairs of data types of one’s mutually recursive set at a time. Thus with the Uniplate 
library you cannot easily do traversals of a structure that simultaneously modifies two different 
data types at the same time. With Multiplate, there is no problem creating a plate that modi¬ 
fies two different data types at the same time. The Multirec library [17] requires the user to 
build an isomorphism between one’s mutually recursive data type and another data type built 
out of higher order fixpoint combinators and makes extensive use of GADTs and type families. I 
believe the definitions for Plates and the Multiplate instances required to use Multiplate are 
much simpler, and the use of rank 3 polymorphism is a milder requirement for the compiler. 

The Multiplate class is currently a little unsatisfying. It would be more natural to define the 
primitive functions as multiplate, idPlate, composePlate, and mapPlate, which is all that is 
required to state the Multiplate laws. Although purePlate and kleisliComposePlate can be defined 
in terms of those primitive functions, I do not know how to define appendPlate. Also, although 
mkPlate is sufficient to define all the functions needed, it seems unnecessarily strong. Further 
research is needed to refine the Multiplate class. I suspect that the mkPlate function can be elim¬ 
inated thus dropping the requirement for rank 3 polymorphism down to rank 2 polymorphism. 

It seems natural to extend the title’s analogy from Applicative to Monad; however the class of 
functors that are monads is not closed under composition. Thus monads do not have the neces¬ 
sary monoidal structure. On the other hand, Alternative functors are closed under composition. 
It may be fruitful to study how this analogy might extend to Alternative. 
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